Charging in telecommunications network

ABSTRACT

A method and a system for collecting session-specific event data in a tele-communications network where sessions are connected through a number of network entities which generate event data and have mutual signaling con-nections. The objective of the invention is to provide a solution whereby event detail records relating to one session but generated by a number of different network entities are sent in a centralized manner in real-time to a given collecting network entity. Thus, the event data combination is optimized and the unnecessary transmission of event detail records from one collecting network entity to another is avoided.

FIELD OF THE INVENTION

[0001] The present invention relates generally to charging in atelecommunications network.

BACKGROUND OF THE INVENTION

[0002] A third generation mobile communications system is in Europenamed UMTS (Universal Mobile Telecommunications System). It is a part ofthe International Telecommunications Union's IMT-2000 system.UMTS/IMT-2000 is a global wireless multimedia system, which provideshigher transmission speed (2 Mbit/s) than the existing mobile networks.

[0003] UMTS and the General Packet Radio Service (GPRS) in the GlobalSystem for Mobile Communications (GSM) have been developed to providewireless communications services packet-switched as well ascircuit-switched environments.

[0004]FIG. 1a shows with a greatly simplified diagram the UMTS network.Only those network elements that are significant in view of the actualinvention are shown. Of course, the network may contain one or more ofeach network element described in the following, depending on thecapacity of the element, the number of mobile subscribers, and theorganization of the network.

[0005] The user terminals 100 may be multi-mode terminals, which canoperate using at least two radio access technologies, such as UMTS andGSM, for example.

[0006] A Gateway GPRS Support Node (GGSN) 102 is a gateway to externalnetworks, and it acts as a router, routing data packets to and from theGPRS support node currently serving the given GPRS terminal.

[0007] A Serving GPRS Support Node (SGSN) 101 is at the samehierarchical level as the mobile switching center MSC. It maintainsinformation about the GPRS terminal's location inside its service areaand performs security and user access control functions. During datatransfer the serving GPRS support node sends and receives data packetsto and from the given terminal via a base station subsystem. The servingGPRS support node requests routing information and subscriberinformation from the Home Location Register (HLR) 103, where allsubscriber information is permanently stored.

[0008] A UMTS specification allows a network subscriber to have one ormore packet data protocol (PDP) addresses. Each of the addresses isdescribed by one or more packet data protocol contexts in the userterminal, the serving GPRS support node, and the gateway GPRS supportnode. The packet data protocol context can be selectively andindependently activated, modified and deactivated. All packet dataprotocol contexts of a subscriber are associated with the same MobilityManagement (MM) context for the International Mobile Subscriber Identity(IMSI) of that subscriber. When the packet data protocol is set up, thismeans that a communication channel is set up.

[0009] In FIG. 1a the serving GPRS support node and the gateway GPRSsupport node are located in the same domain A. When a connection is tobe set up between a subscriber and the Internet 108, for example, thefirst step is that a mobile terminal 100 sends an active packet dataprotocol context request through a radio access network (RAN) 106 to theserving GPRS support node 101. The message includes a variety ofparameters, which further include a packet data protocol address and anAccess Point Name (APN). The access point name is a logical namereferring to the gateway GPRS support node to be used. Here the accesspoint name refers to the gateway GPRS support node 102, through whichthe data packets are routed between the mobile terminal and theInternet. Several messages are sent between the said network elementsbefore the connection is completed.

[0010] Event (Call/session) detailed data collection is always used whenspecified detailed information on an event (call/session) is requiredfor billing or for the monitoring of event (call/session) details. Thus,each of the network elements collects data pertaining to eachcall/session until a certain predefined limit has been reached. Thelimit is a certain amount of data, time or other definable triggervalues, such as a megabyte, for example. Then the network elementgenerates an event detail record and sends it using an active protocolthrough the IP-network (Internet Protocol network) 107 to a ChargingGateway Function CGF1 104. In general, at least the following networkelements generate event call detail records: the serving GPRS supportnode, the gateway GPRS support node, the call state control function(CSCF), and the Application Server(s) in radio access networks, such asa General Packet Radio Service (GERAN) or a UMTS Terrestrial RadioAccess Network (UTRAN), the latter being a wideband multiple accessradio network currently specified in the 3GPP (Third GenerationPartnership Project). Normally, during one session each of the saidnetwork elements generates a number of event call detail recordsrelating to the session.

[0011] The charging gateway function receives, for example, four eventdetail records pertaining to the same session from the serving GPRSsupport node and four from the gateway GPRS support node and thencombines them with the help of a sequence number found in each eventdetail record. A formatted event call detail record is sent from thecharging gateway function to a Billing Center (BC) 105 for processing.

[0012] A number of problems arise if the method described above is usedas such in the latest release of the third generation mobilecommunications system. Some of the problems are briefly described withreference to FIG. 1b in the following.

[0013] Several millions event detail records are constantly generated ineach of the network elements, such as the serving GPRS support node 101,the gateway GPRS support node 102, the call state control function CSCF109, the application server 110, or some other network element N 111.Then each of the network elements independently passes the call detailrecords to a charging gateway function CGF1-CGFN 112. The problem isthat at the moment there is no mechanism which would automatically inreal-time centralize directly all the event detail records pertaining toone session for the specified charging gateway function (e.g. CGF1) inthe network/domain concerned. By contrast, the event detail records aredirected to a large number of different charging gateway functions. Thisleads to the problem of how to combine those event detail recordspertaining to the same session/call. One solution is to use a standalonedevice, a so-called mediator, for collecting and combining the eventdetail records before sending them for further processing to the billingcenter 106. Combining the event detail records in the mediator is quitecomplicated and time-consuming.

[0014] One solution is to use a unique session identifier for combiningthe right event detail records. This kind of solution is described inthe applicant's earlier U.S. patent application Ser. No. 09/577,152,which has not been published by the filing date of the presentapplication. The identifier is called a global transaction ID (uniquesession identifier.)

[0015] However, that solution does not solve the time-consuming problemabove, i.e. different network elements still send event detail recordsto different charging gateway functions.

SUMMARY OF THE INVENTION

[0016] The present invention relates generally to event detail record(EDRs) collection and management (related to charging, monitoring,lawful interception etc.) in a telecommunications network andspecifically to post-paid and event detail records based pre-paidcharging in a third generation mobile communications network.

[0017] The objective of the invention is to provide a solution wherebyevent detail records relating to one session but generated by a numberof different network entities are sent in a centralized manner inreal-time to a given collecting network entity. Thus, the event datacombination is optimized and the unnecessary transmission of eventdetail records from one collecting network entity to another is avoided.The objective is achieved through a method and system characterized bywhat is stated in the independent claims.

[0018] The idea of the invention is to collect session-specific data ina given collecting etwork entity when user connections during a sessionare connected through a number of network entities generating eventdetail records and having mutual signaling connection.

[0019] Each of the network entities generating event detail records in adomain/network has a corresponding table including a set addresses ofnetwork entities collecting event detail records. The collecting networkentity address is universally unique.

[0020] During connection set up a network entity which receives aconnection/session establishment request selects an address for thecollecting network entity from the said table and proposes that addressto the network entities generating event detail records by inserting theaddress with a unique session identifier to a signaling message to besent to the next network entity which generates event detail records.

[0021] When the network entity that generates event detail recordsreceives the proposed address, it checks whether the address isconfigured in the table of collecting network entities.

[0022] If the proposed address matches a primary address of thecollecting network entity in the configured table, the network entitysends the message further to the next network entity.

[0023] If the proposed address does not match the primary address of thecollecting network entity in the configured table, the network entitychecks whether the next address on the table matches and so on. If theaddress is found, the message is sent to the next network entity asabove.

[0024] If the proposed address is not found in the table, the saidnetwork entity chooses the primary collecting network entity addressfrom the table, replaces the proposed address with it, and sends themessage to the next network entity.

[0025] In cases where the proposed collecting network entity is not inuse or does not respond, the network entity in question replaces theproposed address by the next address from the configured table and sendsthe message to the next network entity.

[0026] All event detail records pertaining to the session/call inquestion are sent in real-time during the session/call to the samecollecting network entity address thus selected.

[0027] The combining of the event detail records relating to the sessionis performed using the unique session identifier in this specifiedcollecting network entity.

[0028] Thus, event detail records generated from several networkentities related to one session/call are centralized in the samecollecting network entity. This speeds up the actual combining of theevent detail records.

[0029] The solution is dynamic and simplifies the transmission of theevent detail records in the network regardless of whether the networkentities are in the same or different networks/domains.

BRIEF DESCRIPTION OF THE DRAWINGS

[0030] The invention is described more closely with reference to theaccompanying drawings, in which

[0031]FIG. 1a illustrates with a simplified diagram a third generationmobile communications system;

[0032]FIG. 1b depicts a prior art solution for sending call detailrecords in a tele-communications network;

[0033]FIG. 2 shows as a block diagram an example of the implementationof the method according to the invention;

[0034]FIG. 3 is a signaling chart showing an example of a basicconnection setup;

[0035]FIG. 4 illustrates a charging gateway address transmission in onedomain in the third generation mobile communications network;

[0036]FIG. 5 illustrates a charging gateway address transmission in onedomain in the third generation mobile communications network;

[0037]FIG. 6 illustrates a charging gateway address transmission in twodomains in the third generation mobile communications network.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

[0038] In the following, a dynamic real-time event detail recordcollection and management in a third generation mobile communicationssystem or a All IP (3GPP rel.5) network is described. However, it isunderstood that the invention is not restricted to UMTS all-IP networksbut can also be implemented in any kind of network where there is a needto use a dynamic real-time event detail record collection andmanagement.

[0039] The idea of the method described in the following is toconcentrate the transmission of event detail records produced indifferent network elements in a telecommunications network in aspecified collecting network entity.

[0040] Hereafter the event detailed records will also be termed EDR, theserving GPRS support node termed SGSN, the gateway GPRS support nodetermed GGSN, the charging gateway function termed CGF, the applicationserver termed AS, and the call state control function will be termedeither CSCF or CPS (call processing server).

[0041] The invention is now described in detail with some examplesreferring to FIGS. 2-6. The event data is charging data and the networkentities are network elements in the following example.

[0042]FIG. 2 illustrates one way of implementing the functionalityrequired to increase the efficiency of charging.

[0043] To overcome the problem of time-consuming charging datacombination and the irrelevant transmission of event detail recordsbetween different charging gateway functions, each network element inthe domain/network sends the EDRs related to one session/call to thesame CGF. Thus, the network elements SGSN 201, the GGSN 202, theapplication server 203, and the CPS 204 transmit all EDRs via a Gainterface in the UMTS all-IP network to the CGF 205.

[0044] It is important to note that this is just a very simplifiedexample. Globally the UMTS network comprises several network elements,each of which is continually producing millions of event detail records.

[0045] In FIG. 3 a voice call set up is considered as an example. Asignaling diagram shows the basic connection setup in the 3GPP rel.5network. The signaling messages mentioned here are just examples, andthere can also be many other kinds of signaling messages. This exampleindicates only one of the possible ways of transferring the CGF addressbetween network elements exchanging signaling messages pertaining to thecall/session. Alternatively, the user terminal could also be involved inthe process of transferring the unique session identifier and the CGFaddress.

[0046] The call set-up signaling is symmetric between the callingsubscriber and the application server, on the one hand, and between theapplication server and the called subscriber, on the other. Therefore,it is enough to examine only one side of the signaling chart.

[0047] It is assumed that the packet data protocol PDP context has beenactivated. As already stated above, each packet data protocol contextcan be selectively and independently activated, modified, anddeactivated.

[0048] A calling party, mobile subscriber A, wants to make a voice callto a called party, who in this particular example may be another mobilesubscriber B. In spite of the voice call, the connection can also be asession, i.e. from the subscriber to a video server, or a network game,etc., depending on the user terminal and service providers.

[0049] The user terminal sends via the serving radio access network RAN,the SGSN, and the GGSN, an INVITE message 300 to a call state controlfunction CSCF or more accurately to a proxy call state control functionP-CSCF.

[0050] The call state control function CSCF can be divided into twological parts, i.e. the CSCF can act as the proxy CSCF or a serving CSCF(S-CSCF). The CSCF handles several functionalities such as: acting as afirst entry point and performs the routing of incoming calls; it reportscall events for billing, auditing, intercepting, or other purposes; itmay provide a server trigger mechanism; it receives and processesapplication level registration; it notifies the home domain of theinitial user's access (e.g. the CSCF signaling transport address and theuser ID).

[0051] The P-CSCF is a first contact point for the user terminal withinthe Internet protocol multimedia subsystem (IMS). Every user terminalalways has a proxy CSCF associated with it and located in the samenetwork.

[0052] The INVITE message 300 is a request “I want to establish a voicecall connection to subscriber B”. In response to the received message,the proxy CSCF generates a unique Call-ID, identifies from a configuredlist a charging gateway to be used as a primary charging gateway intowhich all EDRs generated during the call are sent, stage 301. These twounique parameters are stored into a memory, and the parameters are alsoadded to the received message. The Call-ID is available for IPMultimedia Core Network Subsystem (IMS) EDRs.

[0053] From now on the said charging gateway is to be called by the nameof proposed charging gateway function, proposed CGF, or proposed IPv6CGF address (IPv6=Internet Protocol version 6).

[0054] At stage 302 the P-CSCF sends a SIP INVITE message, including theCall-ID and the IPv6 address of the proposed charging gateway, to theserving CSCF (S-CSCF) where the call/session states are handled. Thenthe P-CSCF starts to establish the call connection. The Call-ID isavailable for IMS EDRs.

[0055] The session initiation protocol SIP is an application levelsignaling protocol used for establishing sessions in an IP network. Asession can be a simple two-way telephone call or a collaborativemultimedia conference session. The SIP is a protocol for creating,modifying, and terminating sessions with one or more participants. Italso supports user mobility and redirects requests to the user's currentlocation.

[0056] The S-CSCF analyzes the destination address and determineswhether the subscriber is of the same or a different network operator.The S-CSCF also checks whether the proposed CGF address matches theprimary CGF address in the configured list of the CGF addresses. If theresult of comparison is TRUE, i.e. the addresses are the same, all theEDRs produced in the S-CSCF relating to this particular call will betransmitted to the proposed CGF address. The proposed CGF address isincluded in messages between different network elements concerning thisparticular call in the beginning and during the call establishmentphase. The checking of the proposed CGF address from the configured listof the CGF is repeated from now on by every network element receivingthe messages pertaining to this call.

[0057] If the proposed address does not match the primary address of thecharging gateway function in the configured list, the network elementchooses the next charging gateway function address from the list,replaces the proposed address with it, and sends the message along withthe unique session identifier to the next network element.

[0058] Also in cases where the proposed charging gateway function is notin use or does not respond, the network element in question replaces theproposed address with the next address from the configured list.

[0059] Next, at stage 303 a SIP INVITE message along with the Call-IDand the IPv6 address of the proposed charging gateway is sent from theS-CSCF to an application server. The Call-ID is available forapplication server EDRs. The application server acknowledges thereceived message by sending the RESPONSE message 304 to the S-CSCF.

[0060] In response the S-CSCF sends the SIP INVITE message 305 includingthe Call-ID and the IPv6 address of the proposed charging gateway to aninterrogating CSCF (I-CSCF). The I-CSCF is the contact point within anoperator's network for all connections destined to a subscriber of thatnetwork operator. The Call-ID is available for IMS EDRs.

[0061] The first task is now to find out where the called subscriber islocated and whether the subscriber's mobile terminal is free to take avoice call.

[0062] When the location of the mobile terminal is made known and it isfree to receive calls, the OK message 306 informing that the connectioncan be established is sent from a network element such as S-CSCF locatedin some other operator's network. The message is sent via the CSCF, theGGSN, and the SGSN to the user terminal of the subscriber A.

[0063] Thus far the messages between the above network elements havebeen transmitted through signaling channels, i.e. no traffic channel hasbeen assigned yet. Messages on the lower part of the signaling chart areneeded for media/traffic path establishment.

[0064] At stage 307 the user terminal sends to the SGSN anActivateSecondaryPDP_Context REQUEST message, and the SGSN forwards theCreatePDP-Context REQUEST message 308 to the GGSN. In response to thereceived message the GGSN generates a Charging-ID, which is availablefor SGSN and GGSN EDRs. After that the GGSN sends the AuthenticationREQUEST message 309 to the P-CSCF, which may be based on COPS (commonopen policy service protocol) messages, for example.

[0065] The policy control function is a logical entity, and it controlswhich packets are allowed to pass through the GGSN. In response to themessage the P-CSCF informs the GGSN of its decision on authorizing thePDP Context Activation by sending a DECISION message 310, including theCall-ID and the IPv6 address of the proposed charging gateway. Thiscall-ID is available for PS EDRs.

[0066] The next step is that the GGSN responds to the SGSN with aCreatePDP_Context RESPONSE message 311, including the call-ID, theCharging-ID, and the IPv6 address of the proposed charging gateway. TheCall-ID and the Charging-ID are available for PS EDRs. At stage 312 theSGSN sends an ActivateSecondaryPDP_Context ACCEPT message to the userterminal.

[0067] All EDRs pertaining to this call are sent automatically from eachof the network elements described above to the proposed CGF.

[0068] In the following, the present invention is illustrated with threeexamples in reference to FIGS. 4-6.

[0069]FIG. 4 illustrates a process of sending the unique charginggateway address to be used in one domain in the third generation mobilecommunications system. The unique Call-ID is also transmitted along withthe charging gateway address as described above.

[0070] The numbering in FIG. 4 corresponds to the numbering in FIG. 1 sothat the network elements and networks 100-108 correspond to the networkelements and networks 400-408. Home Subscriber Services (HSS) register403 is enhanced with a Home Location Register (HLR).

[0071] The packet data protocol PDP context has been activated, i.e. thesignaling channel is created between the user terminal 400 and the callstate control function 409. The user terminal has requested connectionestablishment to a called subscriber. Alternatively, the subscriber ofthe user terminal might wish to connect to an application server thatserves multimedia, video, games, etc. The signaling messages needed whenthe connection is set up are sent via the SGSN 401 and the GGSN 402 tothe CSCF. The CSCF analyzes the content of the received message, e.g.the call set up request, and performs actions such as forwarding therequest to a CSCF located in another operator's network. It is shown inFIG. 4 that each of the network elements, i.e. the SGSN 401, the GGSN402 and the CSCF 409, has a configured list of charging gateway functionaddress 410-412. The CSCF selects from the list 410 the charging gatewayfunction address CGF1 to be used by all network elements involved in thesession in question. The proposed charging gateway function address issent along with the message to the GGSN, which in turn sends it alongwith the message to the SGSN. The message transmission and the checkingof the proposed charging address are carried out as above. The lists inthe network elements correspond to one another.

[0072]FIG. 5 also illustrates a process of sending the unique charginggateway address in one domain in the third generation mobilecommunications system. In the figure the packet data protocol PDPcontext has been activated between the user terminal and the application500, and the connection between the user terminal and the application isset up and activated. The CSCF informs the application in the message(described in FIG. 3) of the proposed CGF to be used during theconnection. Messages between the CSCF and the application are sent atthe application layer.

[0073]FIG. 6 illustrates a process of sending the unique charginggateway address in two domains of the third generation network.

[0074] Operator A owns the network in domain A, and operator B owns thenetwork in domain B. The configured lists differ from each other in thenetwork elements of different network owners. The CSCF 409 proposes theCGF5 address to the GGSN 402, but the GGSN does not find the proposedaddress from its own list. In this case the GGSN selects from its list aprimary charging gateway function CGF1, replaces the CGF5 address withit, and forwards the message to the SGSN.

[0075] A subscriber may simultaneously have a number of activecalls/sessions' such as a voice call, e-mail, a video session. With thehelp of the unique identifier, it is possible to trace in detail thecharging information generated e.g. distinguish from the charginginformation as to how much data volume was transferred during the voicecall, the e-mail, or the video session.

[0076] By means of the unique session identifier along with the uniquecharging gateway address, which are sent from one network element to thenext network element, it is possible to achieve fast, clear, and dynamiccharging as well as activities relating to monitoring, collectingstatistics, and lawful interception.

[0077] Although the invention is designed to be especially suitable forthe third generation mobile communications system, the invention is notlimited to application for such system. It is clear that the describedcharging method and system can be installed in networks of any kind. Ofcourse, also the user terminal can be of any kind. In addition, theunique session identifier and the CGF address can be delivered to theuser terminal and then to the other network elements generating chargingdata in order to ensure that the unique session identifier and the CGFaddress are delivered to all those network elements involved in thesession/call in question.

[0078] Implementation and embodiments of the present invention have beenexplained above with different examples. However, it is understood thatthe invention is not restricted by the details of the embodiments aboveand that numerous changes and modifications can be made by those skilledin the art without departing from the characteristic features of theinvention. The described embodiments are to be considered illustrativebut not restrictive. Therefore the invention should be limited only bythe attached claims. Thus, alternative implementations defined by theclaims, as well as equivalent implementations, are included in the scopeof the invention.

What is claimed is:
 1. A method for collecting session-specific eventdata in a network where user connections during a session are connectedthrough a number of network entities generating event data and having amutual signaling connection, characterized by the steps of storing ineach of the network entities generating event data a set of addressesfor the network entities collecting event data, during connection set-upchoosing one address of a collecting network entity from the set in eachof the event data generating a network entity, and during the connectionsending event data which is being generated during the connection to thenetwork entity chosen.
 2. A method according to claim 1, characterizedin that the address of the collecting entity is globally unique.
 3. Amethod according to claim 1, characterized in that during the connectionset-up a predetermined network entity receives a session/connectionestablishment request, selects the said address from the set, andindicates it to the other network entities generating event data byinserting the address in the signaling messages which it sends duringthe connection set-up.
 4. A method according to claim 3, characterizedin that a globally unique identifier pertaining to the said session isinserted in the said message.
 5. A method according to claim 3 or 4,characterized by receiving a signaling message including the saidaddress, comparing the said address with a primary address of the set,and if the addresses compared are equal, sending the message to the nextnetwork entity, whereby said receiving and comparing steps are performedin the network entity which generates event data.
 6. A method accordingto claim 3 or 4, characterized by receiving a signaling messageincluding the said address, comparing the said address with a primaryaddress in the set, and if the addresses compared fail to correspond toeach other, replacing the received address with the primary addressselected from the set and sending the message to the next networkentity, whereby said receiving and comparing steps are performed in thenetwork entity which generates event data.
 7. A method according toclaim 1, characterized in that the network entity is a network element.8. A method according to claim 1, characterized in that the networkentity is a user terminal.
 9. A method according to claim 1,characterized in that the content of the set is identical at least inthe network entities within the same domain.
 10. A method according toclaim 1, characterized in that the content of the set is identical atleast in the network entities within the same network.
 11. A methodaccording to claim 1, characterized in that the stored set of addressesof the network entities generating the event data is in the form of atable.
 12. A method according to claim 1, characterized in that theevent data includes charging data.
 13. A communication system comprisingat least the routing network entities and the network entitiesgenerating the event data and the network entities collecting the eventdata, characterIzed in that each of the event data generating networkentities includes a set of addresses for the network entities collectingevent data, selecting means for choosing from the set one address of acollecting network entity, signaling means for signaling selectedaddresses between network entities generating event data, sending meansfor sending event data generated during a session to the address chosenby the selection means.